(RFP) Kubernetes 아키텍처

Kubernetes 를 활용한 현대적 컨테이너 기반 마이크로서비스 아키텍처
Pasted image 20250909152306.png

아키텍처 개요

Week 4까지의 전통적인 VM 기반 아키텍처에서 한 단계 더 발전한 클라우드 네이티브 컨테이너 플랫폼입니다. Kubernetes를 기반으로 한 마이크로서비스 아키텍처로, 현대적인 애플리케이션 개발과 운영의 모범 사례를 보여줍니다.

실제 구현된 아키텍처

상단 이미지는 실제 운영 중인 EKS 클러스터의 마이크로서비스 아키텍처입니다.

Kubernetes 클러스터 구성:

마이크로서비스 구조:

왜 EKS 아키텍처인가?

Week 4의 한계점

기존 VM 기반 아키텍처의 문제:
├── 느린 배포 속도 (인스턴스 시작 시간)
├── 리소스 낭비 (VM 오버헤드)
├── 복잡한 의존성 관리
├── 환경별 차이로 인한 버그
└── 스케일링의 한계 (인스턴스 단위)

EKS의 해결책

컨테이너 기반 아키텍처의 장점:
├── 빠른 배포 (초 단위 Pod 시작)
├── 높은 리소스 효율성 (컨테이너 공유)
├── 일관된 환경 (도커 이미지)
├── 세밀한 스케일링 (Pod 단위)
└── 마이크로서비스 아키텍처 지원

핵심 구성 요소

1. Kubernetes 클러스터 인프라

Control Plane Nodes (고가용성):

마스터 노드 (3개):
├── prd-master-1 (4 Core, 8GB)
├── prd-master-2 (4 Core, 8GB)
├── prd-master-3 (4 Core, 8GB)
└── etcd, API Server, Scheduler, Controller Manager

Worker Nodes (애플리케이션 실행):

워커 노드 (4개):
├── prd-worker-1 (10 Core, 32GB)
├── prd-worker-2 (10 Core, 32GB)
├── prd-worker-3 (10 Core, 32GB)
├── prd-worker-4 (10 Core, 32GB)
└── 마이크로서비스 Pod 실행

Ingress Nodes (트래픽 진입점):

인그레스 노드 (2개):
├── ingress-1 (4 Core, 8GB)
├── prd-ingress-2 (4 Core, 8GB)
└── API Gateway, 로드 밸런싱

2. 마이크로서비스 아키텍처

Frontend Services (사용자 인터페이스):

Admin Frontend Service:
├── 관리자 대시보드
├── 시스템 관리 기능
├── Scale: 2-4 Pods, Threshold: 70%
└── frontend-admin-prd 배포

User Frontend Service:
├── 고객 웹 인터페이스
├── 사용자 경험 최적화
├── Scale: 2-4 Pods, Threshold: 70%
└── frontend-user-prd 배포

BFF Services (Backend for Frontend):

Admin BFF Service:
├── 관리자 전용 API 조합
├── 권한 및 보안 처리
├── Scale: 2-4 Pods, Threshold: 90%
└── backend-admin-bff-prd 배포

User BFF Service:
├── 사용자 전용 API 조합
├── 성능 최적화
├── Scale: 4-6 Pods, Threshold: 60%
└── backend-user-bff-prd 배포

Core Backend Services:

Calculate Service:
├── 계산 및 연산 처리
├── Scale: 2-4 Pods, Threshold: 90%
└── calculate-prd 배포

Market Service:
├── 시장 데이터 처리
├── Scale: 2-4 Pods, Threshold: 90%
└── market-prd 배포

Payment Service:
├── 결제 처리 시스템
├── Scale: 2-4 Pods, Threshold: 90%
└── payment-prd 배포

Product Service:
├── 상품 관리 시스템
├── Scale: 2-4 Pods, Threshold: 90%
└── product-prd 배포

User Service:
├── 사용자 관리 시스템
├── Scale: 4-6 Pods, Threshold: 60%
└── user-prd 배포

Stats Service:
├── 통계 및 분석 처리
├── Scale: 2-4 Pods, Threshold: 90%
└── stats-prd 배포

자동 스케일링 전략

서비스별 HPA 설정

고부하 서비스 (Threshold: 60%):
├── User Service: 4-6 Pods
├── User BFF Service: 4-6 Pods
└── 사용자 트래픽 집중 대응

일반 서비스 (Threshold: 70%):
├── Frontend Services: 2-4 Pods
├── 안정적인 사용자 인터페이스 제공
└── 예측 가능한 부하 패턴

중요 서비스 (Threshold: 90%):
├── Calculate, Market, Payment, Product, Stats: 2-4 Pods
├── 높은 안정성 요구
├── 신중한 스케일링 정책
└── 리소스 효율성 극대화

실제 운영 메트릭

Pod 분산 현황:
├── Frontend Layer: 8-16 Pods
├── BFF Layer: 6-10 Pods
├── Backend Layer: 12-24 Pods
├── 총 Pod 수: 26-50개
└── 클러스터 리소스 사용률: 60-80%

데이터베이스 아키텍처

DBaaS for MySQL 8

메인 데이터베이스:
├── MySQL 8.0 기반 관리형 서비스
├── 8vCPU, 32GB 메모리 구성
├── Master-Slave 복제 구조
├── 고가용성 및 자동 백업
└── 모든 마이크로서비스 연결

읽기 전용 복제본

Read Replica 구성:
├── DBaaS for MySQL 8 (Read)
├── 8vCPU, 32GB 메모리
├── 읽기 부하 분산
├── 분석 쿼리 전용
└── 성능 최적화

데이터베이스 연결 패턴

서비스별 DB 접근:
├── Calculate → Master DB (계산 결과 저장)
├── Market → Read Replica (시장 데이터 조회)
├── Payment → Master DB (결제 트랜잭션)
├── Product → Read Replica (상품 조회)
├── User → Master DB (사용자 정보 관리)
├── Stats → Read Replica (통계 분석)
└── 읽기/쓰기 분리로 성능 최적화

마이크로서비스 통신 패턴

API Gateway 패턴

외부 요청 흐름:
1. 사용자 → Ingress Controller
2. Ingress → API Gateway
3. API Gateway → BFF Services
4. BFF → Backend Services
5. Backend → Database

BFF (Backend for Frontend) 패턴

Admin BFF:
├── 관리자 전용 API 조합
├── 권한 검증 및 보안 강화
├── 복잡한 비즈니스 로직 처리
└── Admin Frontend 최적화

User BFF:
├── 일반 사용자 API 조합
├── 성능 최적화 중심
├── 캐싱 및 응답 최적화
└── User Frontend 최적화

서비스 간 통신

동기 통신 (REST API):
├── Frontend ↔ BFF
├── BFF ↔ Backend Services
├── Backend Services ↔ Database
└── 실시간 응답 필요 영역

비동기 통신 (이벤트 기반):
├── Payment → Stats (결제 완료 이벤트)
├── User → Market (사용자 행동 분석)
├── Product → Calculate (재고 계산)
└── 느슨한 결합 유지